Data replication system and method

ABSTRACT

System and method for sub-second data replication. The present invention provides the ability to replicate database transactions made on one computer to one or more local or remote computers instantly, utilizing the database management system&#39;s transaction log for the replication. The present invention intercepts transactions being sent to a database&#39;s transaction log and interprets and copies the transactions to one or more replica servers, as well as to the original existing database transaction log. This enables real-time reporting without taxing the transaction system, real-time backup and immediate disaster recovery, by offloading said activities from the transaction server to a replica server that synchronized with the transaction server in real-time. The system comprises a central server and a set of source and destination agents that can reside all in a local system, or can be remotely connected such as through a TCP/IP networks The central server controls a series of loadable modules to perform specific functions in the system, and an agent that runs on every machine in the system that has a relational database management system running. The agent is either a source agent, gathering data from a source database server, or a destination (or target) agent, applying the data to the destination database, or both a source and destination agent.

BACKGROUND OF THE INVENTION

Enterprises produce increasingly vast volumes of data and demand itsbroad availability that challenges products to deliver high reliability,disaster protection, and real-time access without degrading enterpriseapplication performance. The ability to query the most up-to-date datawith reporting and analysis tools is increasingly critical for companiesas they strive to gain deeper and faster insight into their dynamicbusiness.

Conventional reporting methods place a high server load on criticaldatabases systems. As a result, creating reports from the transactionalsystem is usually kept to a minimum. Although applications for reportingand analysis may target replica databases instead of directly taxing theapplication source database, traditional replication methods, which mayhave significant data lag between the source and target, are typicallyhours or even days out of synchronization with the content of the masterdatabase.

Conventional disaster recovery systems utilize a secondary site, instand-by mode, that is refreshed on a batch or interval basis. If adisaster occurs, the secondary site must be taken out of stand-by modeand placed in active mode, and an integrity check is performed on thedatabase prior to bringing the application environment back online. As aresult there can be a significant time lag between disaster andrecovery, as well as, significant data loss due to the batch or intervalrefresh of the secondary site causing a time lag between the primarysite updates and the last secondary site update before the disaster.

For most database management systems, transactions are logged totransaction files in binary format after the database operation has beencommitted to the database.

It would be desirable to provide real-time data replication forrelational databases, enabling multiple databases to hold current andconsistent data regardless of their physical location.

It is therefore an object of the present invention to provide a systemand method for real-time reporting without taxing transaction systemsregardless of the number of queries.

It is a further object of the present invention to provide a system andmethod for real-time data backup without stopping or interrupting theone or more applications running.

It is still a further object of the present invention to provide asystem and method for immediate disaster recovery.

SUMMARY OF THE INVENTION

The problems of the prior art have been overcome by the presentinvention, which provides a system and method for sub-second datareplication. The present invention provides the ability to replicatedatabase transactions made on one computer to one or more local orremote computers instantly, utilizing the database management system'stransaction log for the replication.

More specifically, in a conventional database application, the user'sclient application sends transactions to the database server. Thedatabase management system first commits the transaction to thedatabase's storage medium then writes the transactions to its“transaction log”. The transaction log maintains a record of allactivity associated with the database. In the event that the databasefails, this log file can be used to reconstruct the contents of thedatabase. The present invention interposes a simulated transaction logbetween the database management system and the database transaction log,thereby intercepting transactions being sent to a database's transactionlog. It then interprets and copies the transactions to one or morereplica servers, as well as to the original existing databasetransaction log. This enables real-time reporting without taxing thetransaction system, real-time backup and immediate disaster recovery, byoffloading said activities from the transaction server to a replicaserver that synchronized with the transaction server in real-time. Theinvention is particularly applicable to an enterprise comprising one ormore physically separate operating environments, each operatingenvironment having a database server interfacing with one or moreapplication servers, each database server having a transaction logadapted to receive a transaction from the database server.

In accordance with a preferred embodiment of the present invention, thesystem comprises a central server and a set of source and destinationagents that can reside all in a local system, or can be remotelyconnected such as through a TCP/IP network. The central server controlsa series of loadable modules to perform specific functions in thesystem, and an agent that runs on every machine in the system that has arelational database management system running. The agent is either asource agent, gathering data from a source database server, or adestination (or target) agent, applying the data to the destinationdatabase, or both a source and destination agent.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a flow diagram of the system architecture in accordance withthe present invention.

FIG. 2 is a flow diagram of the system architecture in a secondembodiment of the present invention.

FIG. 3 is a flow diagram of the system architecture in a thirdembodiment of the present invention.

FIG. 4 is a flow diagram of the system architecture in a fourthembodiment of the present invention.

Appendix 1 is pseudo code describing the specific code modules in thepresent invention.

DETAILED DESCRIPTION OF THE INVENTION

The replication system of the present invention comprises four primarycomponents, namely, a device driver, a source agent, a destination ortarget agent and a central hub or server.

A device driver consists of a set of routines that control a systemdevice (i.e. hard drive, mouse, monitor, keyboard). A device driver isinstalled on the source database server to simulate a regular disk fileor raw device on the source system's operating system. The importantoperations that can be performed on it are read, write and seek. Theoriginal transaction log files pre-existing in the source database aremoved to another directory for disaster recovery purposes. This allowsthe same transaction log file names to be linked to the created device.Accordingly, when a new or updated transaction is written out to thetransaction log file, the device driver is able to “intercept” thetransactions, and the transaction is instead written out to the devicedriver, since the device driver is now posing as the originaltransaction log file. Thus, when the database manager attempts to writeany transaction step to the log file, it is instead written to thedevice driver, which then places it in an in-memory queue for the sourceagent to read. When the source agent reads from the in-memory queuepopulated by the device driver, it writes the binary informationcontained in the queue to the central hub, it at the same time alsowrites a copy to the original transaction log files residing in thenewly designated directory. In case of disaster, these newly designatedtransaction log files can be used to restore the database to its lateststatus since they are always in synchronization with the targetreplicated database.

Referring to Appendix 1, page 1, lines 30-60, this pseudo-codeinitializes the device driver and allocates the memory needed for databuffers. Page 2 explains the various actions of the device driver. TheRead_from_Driver routine, lines 1-28, is executed when the Source Agentqueries the device driver for new transactions. The routine simplycopies the data passed to it by the database application to user space.The Seek_on_Driver routine, lines 30-44 and the Write_to_Driver routine,lines 46-55 are executed when the dB application accesses what itbelieves to be the transaction log. The device driver emulates thebehavior of the log file so that the database application continucs tofunction as designed.

Turning now to FIG. 1, a source database 2 is in communication withsource database storage 5, such as a disk or other storage medium, and adevice driver 3. When a client application 1 (which application is notparticularly limited, and by way of example can include human resourceapplications, customer relationship management and enterprise resourceplanning) writes to the source database, and, in turn, the sourcedatabase writes to the source database 2 transaction log, the data isintercepted by the device driver 3 which queues the transaction. Thedriver 3 sends a signal to the source agent 4 to notify it that there isa transaction pending. In response, the source agent 4 fetches thetransaction, and writes it to the physical transaction log 6. The sourceagent 4 also forwards the transaction to a Central Server 7, such as viaa TCP/IP connection. The Central Server 7 preferably converts theincoming transaction data from the database transaction log proprietaryformat to a generic statement (e.g., ANSI SQL), and sends a copy of thistransaction to one or more destination agents 8 a, 8 b identified asreceiving a replica of this data. The one or more destination agents 8a, 8 b apply the data to the destination database 9 a, 9 b, respectively(each having a respective database storage 10 a, 10 b), via nativedatabase methods appropriate for their database management system.

For example, for DB2, there are three transaction log files in the DB2designated directory, namely, S0000000.LOG, S0000001 LOG andS0000002.LOG. The installer for this invention moves these files to anew directory and links them to the generated devices. Corresponding tothe three log files, there are six devices, namely, /dev/paralleldb0(master) and /dev/paralleldb1 (slave) for S0000000.LOG; /dev/paralleldb2(master) and /dev/paralledb3 (slave) for S0000001 LOG; and/dev/paralleldb4 (master) and /dev/paralleldb5 (slave) for S0000002.LOG.The master devices are associated with their own section of memorybuffers and they are the location where DB2 writes the transactionsteps. In order to ensure that only it can manipulate the memory pointerin a memory buffer, the agent copies the memory buffer to anothersection of memory for each slave device. The agent read operation thusactually happens against the slave devices instead of the masterdevices.

The source agent and destination agent are also primary components ofthe present invention. The source agent resides on the transactionserver whose database is to be replicated. The destination agent resideson the system that will replicate the database of the transactionserver.

Initially during start-up of the system, the agents wait to be contactedby a central server, such as over a special TCP port. When a usercreates a relationship on a central server that includes the server thatthe agent is residing in, as either a source or destination agent orboth, the agent receives its configuration information including theidentity of the central server, which database instance it will beusing, and what its function will be (i.e., source, destination orboth). The agent stores this data locally in a disk configurationdatabase, so that the next time the agent is started, it will read fromthe disk configuration database and be able to start functioningimmediately.

If the agent is acting as a source agent, it contacts the sourcedatabase and (using native database calls) obtains information about theinstance it will be replicating (e.g., table, column names, constraints,etc.). It then caches this information and forwards it, preferably viaTCP, to the central server for use in the SQL translation processdiscussed in further detail below. The source agent then contacts thedevice driver to set a block, and waits to be notified of new dataarriving in the driver.

Referring to Appendix 1, page 3, lines 20-32, the main thread of theagent continuously checks for requests from the replicator forinformation concerning connections or configuration information. Uponreceiving such a request, it processes the request and returns theinformation to the replicator.

When the source agent is notified of the arrival of new data, it readsthe transaction log file (in database transaction log proprietaryformat) and sends the transaction binary data to the central server. Thesource agent also is responsive to the central server, thereby enablingthe central server to proceed with the database replication process asdiscussed in greater detail below. Each source agent is responsible forreading the transaction data from the device, via the device driver, sothat it can be sent to the central server replicator. The source agentis also responsible for saving data to the original (pre-existing)transaction log files in the designated area. This is preferably carriedout while the source agent is sending the transaction data to thereplicator component of the central server. In the event of a disaster,the original transaction log files are always ready to be used torecover the database to its latest status without requiring an integritycheck.

Referring to Appendix 1, pg. 3, lines 34-45 the source agent contains aSource thread and a Queue thread. The Source Thread continuously checksthe device driver for new IO. When a new command has been received, itcopies the data to the local transaction log and also places this newdata in the outbound queue. The Queue Thread, p. 3, line 54 to p. 4,line 8, continuously checks the queue for new entries. Upon receipt, itsends the IO to the replicator, and waits for an acknowledgment from thereplicator. When it receives the acknowledgment, the IO is removed fromthe queue. If the acknowledgement is not received, the entry will remainin the queue and will be retried later. This behavior is critical inorder to guarantee delivery and therefore allow the invention to survivenetwork outages and power outages.

Each target or destination agent is responsible for receiving the SQLcommnands sent by the central hub or server, and applying them to thedestination database. Specifically, each destination agent sets up aconnection to the destination database, and awaits data, preferably viaa TCP socket, from the central server. When data are received by thedestination agent, the data have already been translated by the centralserver into a generic language (e.g., ANSI SQL format). The destinationagent applies the data, using OCI or CLI, for example, to thedestination database. The translation by the central server can beparticularly important, since by converting to a generic language, theuse of the system and method of the present invention is not limited bythe databases involved. Those skilled in the art will appreciate,however, that where all databases involved recognize the same language(e.g., they are from the same manufacturer), the central server could beused in a pass through mode where translation to a generic language isnot necessary.

Referring to Appendix 1, page 4 lines 10-17, the Destination Threadcontinuously polls for new SQL commands from the replicator. Uponreceipt of a command, it applies it to the target database via a nativedatabase connection. Once the operation has been successfully performed,it returns an acknowledge to the replicator, signaling to the hub thatthis command can be removed from the queue.

The central hub is composed of three major components: the ManagementConsole, the Controller and the Replicator.

The Management Console is for configuration. Preferably configuration iscarried out via a web browser, and the Management Console is both anHTTP server and a Web-based graphical user interface (GUI) responsiblefor hosting the HTML management console and supporting customer actionsdirected from the console GUI. Through the Web GUI, users can definesource/destination agents relationships and specify locations of thetransaction log files and devices. The Management Console also providesa management interface to control the running processes of theReplicator, Controller and Management Console itself.

The Management Console provides two sets of operations, namely, theServer Tasks and the Database Relationships. The Server Tasks allow theuser to turn on or off processes of the Replicator, Controller and theManagement Console. The Database Relationships allow the user to add,modify or delete the source and target database relationships. Once arelationship is added to the system, it is stored in a local IndexedSequential Access Memory (ISAM) database and then the appropriate agentsare contacted (e.g., via TCP) to set up the replication. The sourceagents then sends information to the central server about the instancethey are monitoring. This information is cached on the central serverfor use in the SQL translation process.

Referring to Appendix 1, page 4, lines 29-44, the main threadcontinuously polls for new console commands and acts upon them asrequired.

The Controller is responsible for communicating with the agents in thesystem, i.e., sending relationship changes to the source and destinationagents, and acting on the user configuration changes sent from theManagement Console and notifying the involved agents of the changes.

The Replicator is the hub for the entire database replication process.It is responsible for the caching of the database schema in a binarytree (B-tree), converting transaction steps from binary to ANSI SQLcommands, sending the ANSI SQL commands to all destination agents, andhandling replication against multiple database instances. Thetransaction binary log data are composed of a continuous stream ofschema or catalog information, tables and records. Internal to thedatabase management system, each table is represented by numbers, i.e.,table 1, table 2, etc. Internally, the database management system alsorepresents the fields in a record by numbers, i.e., field 1, field 2,etc. When the Replicator reads a table number or field number, it makesrequests to the source agent and asks for the table name or the fieldname. The source agent queries the database management system todetermine the name of the table or field represented by the number. Uponreceiving the response from the source agent, the Replicator caches thetable name or field name into a B-tree. The Replicator parses theincoming transaction binary log data, converts them to a string of SQLcommands. The Replicator inspects the incoming log data, looking fortransaction/operation terminators to determine what the completetransaction was. It then sends the resultant SQL commands to one or moredestination agent, such as via TCP sockets, that are identified as atarget of that instance in a relationship.

Referring to Appendix 1, page 5, lines 12-39, the Source Agent Threadgets incoming log information from the source agent. Then, afterreceiving a terminator, converts the binary log information into SQLcommands, and then queues these commands for each destination. Once thisis completed, an acknowledgment is sent to the Source Agent, allowing itto remove this item from its queue.

The Destination Agent Thread, p. 4, line 53 to p. 5, line 10, monitorsthe queue for new SQL commands, and sends these commands to thedestination. Once an acknowledgment is received from the destination,the item is removed from the queue. This is done to guarantee successfuldelivery even in the presence of network outages. There can be multipleinstantiations of this thread to allow multiple destination replicas ofthe source database.

The user may choose to encrypt the resultant SQL commands before sendingthem to the destination agents to maintain the secrecy of the data. Forexample, if the destination agent is located on a server accessed viaTCP/IP across the Internet, encryption can be used to insure theconfidentiality of the information. At the user's discretion the SQLcommands can also be compressed to minimize network traffic originatingfrom the central hub.

The system is able to handle multiple threads of source/destinationrelationships because the Replicator maintains a linked list ofconverted SQL commands for each relationship thread. The SQL commands inthe linked list are consumed by sending them out to the destinationagent.

Underlying all of the components of the system of the present inventionis an operating system translation layer, which implements bothoperating system primitives (semaphores, spinlocks, queues, etc.) andbase level functions such as networking primitives (socket support,pipes, etc.). This layer also helps implement a key feature of thearchitecture, guaranteed network transport delivery. That is, all of thecomponents in the system simply carry out a TCP send to pass databetween components. The translation networking layer then queues thatdata (including a physical on-disk backup) and continues to forward thedata to its destination until a confirmation is received. Thisguaranteed delivery will survive network outages, power outages and mostsystem failures.

Another important feature of this invention is its ability to continueto operate and assist in disaster recovery. Referring to FIG. 1, sourcedatabase 2 is the primary system, while databases 9 a and 9 b arereplicas of this database. In the case of a disaster, database 2 becomesunusable. Once this condition is encountered, a replica of the primarydatabase becomes the primary machine. Those skilled in the art willunderstand the mechanisms used to facilitate this. At this point,database 9 a, which was a destination, now becomes the primary database.The Central Server 7, simply informs that machine that its agent 8 a isnow to operate as the source agent. Since the specialized code isresident in every agent, the agent simply changes from a destination toa source. It then operates in exactly the same fashion as the originalsource, sending its log information back to the central replicator,where it is processed and passed to destination agent 8 b. In thismanner, database 9 b is still a complete replica of the primary databaseand is kept updated in real time.

The recovery process is still possible even when there is only onedestination database. In that case, when primary database 2 fails, theoperator must intervene to bring a new backup machine online. Thoseskilled in the art can appreciate that there are a number of ways inwhich to copy the contents of database 9 a onto the new backup machine.Once that is completed, the destination agent 8 a is reconfigured to bea source agent, and the agent in the new backup machine is thedestination agent. As above, the central replicator relays SQL commandsto the destination agent.

In a second embodiment, shown in FIG. 2, a second central server isemployed. This topology is useful when the source and destinationdatabases are geographically distributed. FIG. 2 shows the sourcedatabase 10 connected to the first central server 11. This centralserver is located relatively close to the source database, and can alsoconnected to one or more destination database servers 12. A secondcentral server 13 is located a significant distance away, such as acrossthe Atlantic Ocean, from the first central server 11. Destinationdatabases 14, 15 and 16 are located near to the second central server13. As transactions are being logged in the source database 10, it sendsthe information to the first central server 11. This central server thenconverts this information into SQL commands and distributes thesecommands to two servers, destination database server 12 and secondcentral server 13. Central server 13 receives these SQL commands andqueues them for destination databases 14, 15 and 16. In this way, thetrans-Atlantic traffic is minimized, as communications are occurringonly between central server 11 and central server 13. This exampleresults in a 67% reduction in trans-Atlantic network traffic, astransactions are only sent to central server 13, and not to destinationdatabases 14,15 and 16.

It is also possible to combine various elements of this invention in anattempt to minimize system components. FIG. 3 shows an embodimentwherein the functionality of the central server is combined with theserver containing the destination database in a 1:1 data replicationscenario. In this environment, server 30 contains the source relatedelements. The application 20 writes to the database 21 and to its localstorage 22. As before, the data destined for the transaction log isintercepted by the device driver 23. The device driver then alerts thesource agent 24. Source agent 24 sends the binary log information tocentral server 26, and copies it to the new transaction log 25. In thisinstance, the code associated with the central server is resident on thedestination server 31. The central server 26 converts the binary datainto SQL commands and then places them in a queue 27 for the destinationagent 28, which is resident on the same server 31. The destination agent28 then receives the item from the queue 27 and applies it to thedestination database 29, which is also attached to the server 31. Inthis way, the source server 30 remains relatively unaffected by thereplication since most of the central server processing is offloaded tothe destination server.

FIG. 4 shows another embodiment that combines some of the elements ontoa single server. In this instance, the central server functions havebeen combined with the source database server 50. All destinationactions reside on destination server 51. As before, the application 40writes to database 41 and to its local storage 42. The data destined forthe transaction log file is intercepted by the device driver 43. Thedevice driver 43 then alerts the source agent 44. The source agentwrites the information to the transaction log 45, and places it on aqueue 46 to be processed by the central server code 47, which isresident on the source database server 50. The central server code 47processes the binary data, converts it to SQL commands and sends them tothe destination agent 48, which resides on the destination databaseserver 51. The destination agent 48 applies these commands to thedestination database 49. This embodiment reduces the amount of networktraffic generated, as all of the processing and translation to SQLcommands is done of the source database server 50.

pseudo code The pseudo code in broken down into three main modules:   1.The device drive module:     The device driver interposes between thedatabase and the transaction/redo     log. This device driver managesall of the input/output from the database to     the agent queues.   2.The agent module:     The agent module on the source machine receivesbinary data from the     device driver, queues and cachcs time data, andsends the data to pdbCentral     for processing.     The agent module onthe destination machine establishes a native database     connectionwith the database engine on the destination machine. It then    receives Structured Query Language (SQL) commands from pdbCentraland     applies those changes to the database on the destination machinevia the     native database connection.   3. The replicator module (onpdbCentral, which is the hub in the hub and spoke     architecture):    The replicator module resides on pdbCentral. This module manages the    connection between the source database server and the destinationdatabase     server(s). The replicator also manages the translation ofdata from binary     form the Structure Query Language. Device DriverPseudo code Initialize_Driver { Allocate the device contexts (perdevice) Initialize the device contexts (per device) Register driver withsystem Initialize the command queue (per device) } Open_Driver { Grabthe semaphore Update the reference count If (first time in)  If masterdevice  Allocate memory for data buffers  Initialize the data buffers else if slave device  Assign the context pointers Save the contextpointer in the file pointer passed in Release the semaphore }Read_from_Driver { Grab the semaphore If this is the master device  Adda read command to the slave queue  Copy the data from the buffer to userspace else if the is the slave device  Read the next command from theslave queue  Switch on the command  Case READ   Remove the command fromthe queue   Copy the read command to User Space  Case SEEK   Remove thecommand from the queue   Copy the seek command to User Space  Case WRITE  Remove the command from the queue   Copy the write command to UserSpace  Case WRITE_DATA   Remove the command from the queue   Copy thedata for the write to User Space Release the semaphore } Seek_on_Driver{ Grab the semaphore Add a seek command to the queue Switch on Seek_Ptr Case SEEK_END  Set context position to end of buffer  Case Seek_Set Set context position to seek position  Or Else  Add Seek position tocontext position Release the semaphore } Write_to_Driver { Grab thesemaphore Copy the data from User space to kernel space Add a writecommand to the slave queue Add the data to the slave queue Release thesemaphore } Close_Driver { Grab the semaphore Decrease the referencecount If last one out  Deallocate buffers  Unregister the device fromsystem  Deallocate the context blocks Release the semaphore } AgentPseudo code Main Thread { Read configure database to get all sourcecommitments For each commitment, connect to the replicator Loop forever: Check for connections from the replicator  Processreplicator/controller requests   Table info lookup   Column info lookup  Change configuration in database (add/remove commitments)   Create adestination thread } Source Thread {  Open Master/Slave device   Writetransaction log cache to the master device   Start a queue thread toread the outbound data stream   Loop forever     Check the slave devicefor IO       Read slave device       Write data to local transaction logcache       Place the IO in an out bound queue (to the replicator) }Queue Thread {   Loop forever     Check the queue for new IO       SendIO to the replicator       Wait for a predefined time interval for anack from the replicator       If an ack is received from replicator      {         Remove the IO from the queue       }       else       {        Resend IO to the replicator       } } Destination Thread {  Connect the database instance   Loop forever     Read SQL fromreplicator     Apply SQL to target DB instance     Send ack toreplicator } Replicator (pdbCentral) Pseudo code Main Thread { Loopforever   Check for console commands from (console, controller andmconsole)     When a new command arrives service the command(connect/disconnect to     destination agent)       connect - create adestination agent thread to connect & service the       destination(from controller)       disconnect - cause the destination agent threadto disconnect & exit (from       controller)       console command -service the command   Check for a connection from a source agent    When a new connection arrives launch a source agent thread toservice the agent } Destination Agent Thread {   Connect to the targetagent   Create/Find the queue for the target instance   Loop forever    Check SQL command queue for a command     Send SQL command to thedestination agent     Wait for a predefined time interval for an ackfrom the destination agent     {       Remove the SQL command from thequeue     }     else     {       Resend SQL Command to the destinationagent     } } Source Agent Thread {   Get source agent info (Instance,Remote host name)   Initialize the database schema BTree   whileconnection to agent is up   Does agent have data?     Read data from theagent     If data contains an transaction/operation terminator     {      if this is the first and only block of data for thistransaction/operation       {         Convert binary log informationinto SQL         Queue the SQL to all destination agents       }      else       {         Append data to previously received databuffer         Convert data buffer into SQL         Queue the SQL to alldestination agents       }     }     else     {       Append data topreviously received data buffer       Wait for next block of data     }    Send acknowledgement back to source agent }

1. A method for data replication, comprising: providing at least firstand second database servers, each said server interfacing with at leastone application server, said first database server having a sourcetransaction log adapted to receive a transaction from a databasemanagement system, said second database server adapted to receive atransaction; providing a computer program to simulate said sourcetransaction log; monitoring said database management system for receiptof a transaction; intercepting said transaction prior to it reachingsaid source transaction log; sending said intercepted transaction tosaid source transaction log; sending a transaction selected from thegroup consisting of said intercepted transaction and a modification ofsaid intercepted transaction to one or more said second databaseservers.
 2. The method of claim 1, wherein said modification ofintercepted transaction is a translation to a generic SQL statement. 3.The method of claim 1, wherein said at least one application serverinterfaces with at least one user.
 4. The method of claim 1, whereinsaid second database server remains continuously available formodification by an application server.
 5. The method of claim 1, whereinsaid intercepted transaction or said modified intercepted transaction isencrypted prior to being sent to said second database server.
 6. Themethod of claim 1, wherein said intercepted transaction or said modifiedintercepted transaction is compressed prior to being sent to said seconddatabase server.
 7. The method of claim 1, wherein said computer programis a device driver.
 8. The method of claim 1, further comprising acentral server for receiving said intercepted transaction or saidmodified intercepted transaction.
 9. The method of claim 8, wherein saidcentral server sends said intercepted transaction or modification ofsaid intercepted transaction to one or more database servers.
 10. Themethod of claim 8, further comprising directing said interceptedtransaction or said modified transaction from said central server to asecond central server, said second central server further directing saidintercepted transaction or said modified transaction to one or moretarget transaction databases.
 11. The method of claim 8, wherein saidcentral server comprises said second database server.
 12. The method ofclaim 8, wherein said central server comprises said first databaseserver.
 13. The method of claim 8, wherein said central serverconfigures said first database server to act as source and said seconddatabase servers to act as a destination.
 14. The method of claim 13,wherein said central server reconfigures said second database server toact as source when said first database server fails.
 15. A datareplication system, comprising: an enterprise comprising one or morephysically separate operating environments, each operating environmenthaving a database server interfacing with one or more applicationservers such that said enterprise comprises at least one source databaseserver and at least one destination data base server, each databaseserver having a transaction log adapted to receive a transaction from adatabase management system, wherein at least one of said databasemanagement systems implements a source database and at least one of saiddatabase management systems implements a destination database; a sourceprogram associated with said enterprise for intercepting a transactionprior to said transaction reaching said transaction log of at least oneof said source database servers; and a replication program interfacingwith said source program for receiving said intercepted transaction andtransmitting a transaction selected from the group consisting of saidintercepted transaction and a modification to said interceptedtransaction to one or more of said destination database servers.
 16. Thesystem of claim 15, wherein said replication program translates saidtransaction to a generic SQL statement prior to transmitting saidtransaction to said one or more destination databases.
 17. The system ofclaim 15, wherein said replication program encrypts said interceptedtransaction or said modified intercepted transaction.
 18. The system ofclaim 15, wherein said replication program compresses said interceptedtransaction or said modified intercepted transaction.
 19. The system ofclaim 15, wherein said replication program transmits said interceptedtransaction or said modified intercepted transaction to a plurality ofdestination databases.
 20. The system of claim 15, wherein saidreplication program resides on a central server.
 21. The system of claim20, further comprising a second central server for receiving saidintercepted transaction or said modified intercepted transaction fromsaid central server and transmitting the same to a plurality ofdestination databases.
 22. The system of claim 15, wherein saidreplication program resides on said destination database server.
 23. Thesystem of claim 15, wherein said replication program resides on saidsource database server.
 24. The system of claim 15, wherein saidreplication program reconfigures one of said destination databaseservers to act as source database server when said source databaseserver fails.
 25. A method of capturing database transactions in realtime, comprising: providing a database server having a databasetransaction log and a resident database management system for receivinga transaction and forwarding said transaction to said databasetransaction log; interposing a simulated transaction log between saiddatabase management system and said database transaction log; andintercepting in said simulated transaction log any transaction forwardedby said database management system.
 26. The method of claim 25, furthercomprising sending said intercepted transaction to said transaction logand to a replication program.
 27. A system of capturing databasetransactions in real time comprising: a database server having adatabase transaction log for receiving a transaction; and a simulatedtransaction log for intercepting said transaction transmitted to saiddatabase transaction log.
 28. The system of claim 26, further comprisinga computer program for transmitting said intercepted transaction to saidtransaction log and to a replication program.